Convert MATH plugin data into more usable form in UFO #980
Conversation
khaledhosny
force-pushed
the
math-table
branch
from
708e44d
to
50cae88
Compare
Makes sense. It might not allow for efficient representation of boolean data, e.g. |
khaledhosny
force-pushed
the
math-table
branch
from
3b2b23e
to
9e0bf7d
Compare
Thinking more about it, I think also handling this generically will be hard to round-trip. Right now I know that certain font lib keys are actually glyph-level userData, but I have no way of knowing this in the generic case. My use case here is to get the data to ufo2ft (googlefonts/ufo2ft#819) and I’m trying to avoid making ufo2ft side too GlyphsApp-specific, hence trying to make the data here usable for a UFO-only workflow as well. |
khaledhosny
force-pushed
the
math-table
branch
from
2cb8d53
to
2195c70
Compare
| for key, value in ufo.lib.items(): | ||
| if _user_data_has_no_special_meaning(key): | ||
| if _user_data_has_no_special_meaning(key) and key not in special_math_keys: |
There was a problem hiding this comment.
maybe you should add the math keys to _user_data_has_no_special_meaning?
There was a problem hiding this comment.
_user_data_has_no_special_meaning is used in multiple places and in some of them we want to skip MATH key and in others we don’t.
The Glyphs MATH plugin stores its data in master, glyph, and layer
userData. Master and layer userData convert seamlessly to UFO font and
layer lib. Glyph userData, however, have no equivalent in UFO so we
store them in the font’s lib under a per-glyph key prefixed by glyphsLib
prefix, but this is a bit ugly. So this change groups them under two
common keys using the same prefix as the other keys.
So instead of:
<key>com.schriftgestaltung.Glyphs.glyphUserData.braceright</key>
<dict>
<key>com.nagwa.MATHPlugin.extendedShape</key>
<integer>1</integer>
<key>com.nagwa.MATHPlugin.variants</key>
<dict>
<key>vVariants</key>
<array>
...
</array>
</dict>
</dict>
<key>com.schriftgestaltung.Glyphs.glyphUserData.braceleft</key>
<dict>
<key>com.nagwa.MATHPlugin.extendedShape</key>
<integer>1</integer>
<key>com.nagwa.MATHPlugin.variants</key>
<dict>
<key>vVariants</key>
<array>
...
</array>
</dict>
</dict>
We now save:
<key>com.nagwa.MATHPlugin.extendedShape</key>
<array>
<string>parenleft</string>
<string>parenright</string>
....
</array>
<key>com.nagwa.MATHPlugin.variants</key>
<dict>
<key>parenleft</key>
<dict>
<key>vVariants</key>
<array>
...
<array>
</dict>
<key>parenleft</key>
<dict>
<key>vVariants</key>
<array>
...
<array>
</dict>
...
</dict>
We write it to the glyph userData where they belong.
khaledhosny
force-pushed
the
math-table
branch
from
2195c70
to
cc6b691
Compare
The Glyphs MATH plugin makes distinction between userData that does not change per master and stores them in glyph.userDara, and that changes per-master and stores then in layer.userData. When writing to UFO we were maintaining this distinction by keeping the former in font.lib and the layer in glyph.lib. But since a UFO file represent a single master, this distinction makes no much sense, and the UFO data looks split arbitrarily. We now keep both glyph and layer userData in glyph.lib. When converting from UFO to Glyphs if the glyph-level data is different between UFO masters, we issue a warning.
khaledhosny
force-pushed
the
math-table
branch
from
cc6b691
to
2433e3e
Compare
The Glyphs MATH plugin stores its data in master, glyph, and layer userData. Master and layer userData convert seamlessly to UFO font and layer lib. Glyph userData, however, have no equivalent in UFO so we store them in the font’s lib under a per-glyph key prefixed by glyphsLib prefix, but this is a bit ugly. So this change groups them under two common keys using the same prefix as the other keys.
So instead of:
We now save: